1. Field of the Invention
The present invention relates to an apparatus and method for debugging software, and in particular to an apparatus and method that facilitates the identification of exceptions when debugging software for a data processing apparatus.
2. Description of the Prior Art
A typical data processing apparatus may have a processor core arranged to execute a sequence of instructions that are applied to data values supplied to the processor core. Typically, a memory may be provided for storing the instructions and data values required by the processor core. Further, it is often the case that one or more caches are provided for storing instructions and data values required by the processor core, so as to reduce the number of accesses required to the memory.
When debugging the software to be executed by such a data processing apparatus, it is known to use a debugger application executing on a computer (collectively referred to hereafter as a "debugger") to monitor the activity of the data processing apparatus as it executes the software.
The debugger can be arranged to interface with the data processing apparatus via an embedded "In Circuit Emulator" (ICE) unit provided within the data processing apparatus. Typically, such embedded ICE units will contain a few hardware breakpoint units, each hardware breakpoint unit having a number of breakpoint registers for storing attributes of instruction or data accesses that the debugger is interested in identifying, and a breakpoint comparator for comparing the attributes in the breakpoint registers with information received from the data processing apparatus about instruction or data accesses being initiated by the processor core. The breakpoint registers will typically include data registers, address registers and control registers for storing attributes of data, addresses or control signals, respectively. Further, mask fields may be provided to enable "don't care" states to be set up, for example when certain bits of the address are not of interest.
Each hardware breakpoint unit may be arranged to issue a breakpoint signal to the processor core if the breakpoint comparator matches the attributes of the breakpoint registers with corresponding attributes contained in the information about instruction or data accesses received from the data processing apparatus.
The breakpoint signal issued by a hardware breakpoint unit will cause the processor core to stop processing instructions, thereby enabling the debugger to analyse the current state of the data processing apparatus.
When debugging software executed by such a data processing apparatus, it is highly desirable to be able to trap whenever an exception occurs during the execution of the code. An example of such an exception might be a data abort, i.e. where a data memory access occurred to a non-existent memory location. In this case, the memory system would return an error, and the processor would branch to a special routine, known as an "exception routine" via an exception address known as a "vector" address, the exception routine being provided to handle the occurrence of a data abort.
One known technique for identifying an access to such an exception routine is to include in the breakpoint registers of one of the hardware breakpoint units attributes identifying the first instruction of that exception routine. By this approach, when the processor core issues an instruction fetch request including the address of that instruction, then the breakpoint comparator in the hardware breakpoint unit will match the instruction fetch request with the attributes in the breakpoint registers, and will issue the breakpoint signal.
However, there are two main disadvantages to the above approach. Firstly, in most microprocessors there are many different types of exceptions, and hence many different exception routines provided to handle those exceptions, each exception routine having different instruction addresses. Hence, there will typically be many different instruction addresses which would require breakpointing if the above approach were to effectively identify accesses to any of those exception routines. However, due to cost factors (eg silicon cost), an embedded ICE unit typically only contains a small number of hardware breakpoint units, and hence it is undesirable to restrict their use to identifying accesses to exception routines, this process often being termed in the art "Vector Trapping" or "Vector Catching".
As an example, the ARM microprocessor developed by Advanced RISC Machines Limited has eight types of exception, and hence eight exception routines, each with unique instruction addresses, but generally only has two hardware breakpoint units. The eight types of exception, along with their addresses, are indicated below:
______________________________________ ADDRESS EXCEPTION ROUTINE ______________________________________ 0x00000000 Reset 0x00000004 Undefined Instruction 0x00000008 Software Interrupt 0x0000000C Prefetch Abort 0x00000010 Data Abort 0x00000014 Reserved 0x00000018 Interrupt 0x0000001C Fast Interrupt ______________________________________
As will be noted from the table, certain bits of the address are the same for each exception routine. To enable all of these various types of exceptions to be identified by a single hardware breakpoint unit, "don't care" states typically have to be set up in the breakpoint address registers to ensure that the hardware breakpoint unit will identify an access to any of the exception routines. However, using such "don't care" states may mean that the processor core is stopped more often than it needs to.
An alternative approach is to employ a "software breakpoint" technique. When using a software breakpoint technique, a fixed pattern of bits is placed within the breakpoint data registers of a hardware breakpoint unit, and the breakpoint comparator will then always compare the information received about instruction accesses with that fixed pattern. Then, the first instruction of each exception routine is removed from memory and replaced with the fixed pattern of bits. By this approach, when the processor core issues an instruction fetch request to that address, the fixed pattern of bits will be retrieved, and the breakpoint comparator in the hardware breakpoint unit will then match that pattern of bits with the pattern of bits stored in the breakpoint registers, and hence issue the breakpoint signal to the processor core. This breakpoint signal will then cause the processor core to stop processing instructions, so that the debugger can then examine the state of the processor and/or memory.
However, if the software breakpoint approach is adopted, then this means that it is impossible to debug ROM code, since the instructions in ROM cannot be overwritten by the fixed pattern of bits. Further, if the data processing apparatus employs a cache, and if the instruction to be overwritten by the fixed pattern of bits is in the cache, then it may not be possible to overwrite that instruction in the cache, and so that instruction must be flushed from the cache, since otherwise the instruction will be returned from the cache without any access to the memory taking place, and hence without the fixed pattern of bits being retrieved. This is particularly disadvantageous if the code is stored in a "locked-down" portion of the cache, a locked-down portion typically being used to store a number of instructions that are used regularly by the processor core, and/or routines which require deterministic behaviour (ie determinable execution time), and hence should not be overwritten by new instructions retrieved from memory.
Another problem with the above identified techniques is that some microprocessors allow the location of the exception routines, or "vectors" as they are sometimes called, to be changed. For example, the MIPS architecture allows the vectors to move position based on the state of the "Bootstrap Exception Vector" (BEV) bit. For more information on the MIPS architecture, the reader is referred to the publication "MIPS Risc Architecture" by Gerry Kane, Prentice Hall ISBN 0-13-584293-X. The base of the vectors may be changed under software control without the debugger being aware of the change. This may mean that vector accesses are not caught when using the above described breakpoint techniques.
Given the above identified problems with the prior art approaches, it is an object of the present invention to provide an improved technique for identifying exceptions when debugging software.